我们的大多数软件逻辑都是用编程语言编写的，这些语言为我们编写和演进此类逻辑提供了最佳环境。但在某些情况下，将这些逻辑移动到我们的命令式代码可以解释的数据结构中是很有用的——我称之为自适应模型。在这里，我将展示一些 JavaScript 中的产品选择逻辑，并展示如何将其重构为用 JSON 编码的简单生产规则系统。此 JSON 数据允许我们使用不同的编程语言在设备之间共享此选择逻辑，并在不更新这些设备上的代码的情况下更新此逻辑。

这是我通常的 DSL 介绍演讲，但做了一个转 twist，因为我正在与比平时更了解 DSL 的人群交谈。所以本质上，我把它变成了一个关于我如何向人们介绍 DSL 的演讲。

微软 Channel 9 对我、我的同事 Neal Ford 和 Jeffery Snover（PowerShell 的创建者）的采访。主题是 DSL——Neal 和我刚刚在 JAOO 2008 上完成了一个关于该主题的教程，并与 Jeffery 进行了一些很好的对话。

当我参加 DSL DevCon 时，微软的 Channel 9 把我拉去接受 Chris Sells 的采访。

我和 Neal Ford 为 The Server Side Java Symposium 做的主题演讲。我们研究了面向领域特定语言的不断发展的运动，存在哪些类型的语言以及它们为何有趣。如果您正在寻找关于该主题的演讲，那么我更喜欢 JAOO 视频，但这次演讲扩展了一些主题，并且由于 Neal 的存在而更具娱乐性。如果您能找到提取音频流的方法，那么它也可以仅使用音频。

我和 Thoughtworks 首席技术官 Rebecca Parsons（DSL 书籍的撰稿人）一起与 Markus Völter 讨论了 DSL。我们讨论了什么是 DSL、内部 DSL 和外部 DSL 之间的区别，以及何时应该（以及不应该）使用 DSL。

DSL 是否允许业务人员在不涉及程序员的情况下编写软件规则？

当人们谈论 DSL 时，通常会提出业务人员自己编写代码的问题。我喜欢将 COBOL 推论应用于这种思路。也就是说，COBOL 的最初目标之一是让人们在没有程序员的情况下编写软件，我们知道结果如何。因此，当任何计划在没有程序员的情况下编写代码时，我不得不问这次有什么特别之处，可以使它在 COBOL（以及许多其他事物）失败的地方取得成功。

我经常遇到这样的说法，即某些技术将允许用户编写自己的软件，而不再需要程序员。当我听到这一点时，我喜欢记住这是 COBOL 的目标——我们知道结果如何。

我被要求为非技术人员整理一份关于 DSL 的讨论。也许我读了太多 Stephen O'Grady 的文章，但我感到有一种不可抗拒的冲动，想以问答的方式来做这件事。所以它来了。

领域特定语言 (DSL) 的基本概念是一种针对特定类型问题的计算机语言，而不是针对任何类型软件问题的通用语言。领域特定语言已经被讨论和使用，几乎与计算存在的时间一样长。

当 领域特定语言 的话题出现时，一个常见的难题是究竟什么是什么是 DSL，什么不是 DSL。问题在于 DSL 没有精确的定义，并且在 DSL 和其他事物之间存在很大的灰色地带。

编写关于外部 领域特定语言 的棘手问题之一是，我正在走过编程语言社区已经大量追踪的领域。编程语言研究一直是学术活动的一个热门领域，我首先承认，我在这个主题上的深度远不及许多多年来一直在研究这个领域的人。所以不可避免地会出现这样的问题：为什么像我这样的菜鸟认为他可以在这片土地上写一本书？

DSL 支持者需要注意的一个危险是，首先设计 DSL，然后人们使用它。像任何其他软件设备一样，成功的 DSL 也会不断发展。这意味着用早期版本的 DSL 编写的脚本在使用后期版本运行时可能会失败。

最近几周，我一直在玩弄和研究编译器编译器工具。这些工具的一个共同特点是，它们都有一个语法文件，其核心是语言语法产生规则的描述。除了描述语法之外，该文件还向解析器提供有关如何在识别语言元素时处理语言的信息。在大多数编译器编译器工具中，这些指令表示为语法中的动作——通常这些动作被编码为高级语言中的代码片段。

流畅接口 的问题之一是它会导致一些看起来很奇怪的方法。考虑这个例子

我一直在探索外部 DSL 的各种替代语言和语法。我的主要工具之一是 Antlr。通过这种探索，我有一个包含多个类似语法文件的项目，我想在其中使用不同的语法运行基本相同的内容。虽然我现在只有几个语法文件，但我最终可能会得到几十个。

几个月前，我参加了 Eric Evans 的一个研讨会，他谈到了一种我们决定将其命名为流畅接口的特定接口风格。这不是一种常见的风格，但我们认为应该让更多人知道。也许最好的描述方式是举例说明。

Given-When-Then 是一种表示测试的风格——或者正如其倡导者所说——使用 SpecificationByExample 指定系统的行为。这是 Daniel Terhorst-North 和 Chris Matts 作为 行为驱动开发 (BDD) 的一部分开发的一种方法。它作为许多测试框架（如 Cucumber）的结构化方法出现。您也可以将其视为对 四阶段测试 模式的重新表述。

几年前，我当时的同事 Matt Foemmel 对我们用来构建软件的工具感到不满，他设法与 Charles Simonyi 取得了联系，以了解更多关于神秘的 意图软件 的信息。他所看到的给他留下了深刻的印象，他说服我和其他 ThoughtWorker 也参与进来。我们看到的是一个具有惊人潜力的工具，但我们仍然对保密和缺乏发布的紧迫性感到沮丧。这种挫败感在上周结束了。

内部 DSL（通常称为嵌入式 DSL）是一种用现有宿主语言编写的 领域特定语言。这是许多编程语言社区（尤其是 Lisp 社区）中一种常见的思维方式。随着 DSL 成为快速发展的 Ruby 社区中一种常见的思维方式，它现在正受到越来越多的关注。

语言工作台是我在 2005 年创造的一个术语，用于描述一类新的软件开发工具，旨在通过多个集成的 领域特定语言 的丰富环境来构建软件。这些工具距离成为主流还有一段距离，但它们的开发仍在继续，并且仍然很有趣。它们是让我觉得可以显着改变编程格局的少数几件事之一。

当我最近写关于 语言工作台 的文章时，我决定将关于进一步阅读的部分放到我的博客中，以便在出现新内容时更容易报告更新。

我使用非专业程序员这个词来指代那些在编程时并不认为自己是程序员的人。一个整天都在处理电子表格的人就是在编程，而且往往是强度很大的编程。然而，她通常不会称自己为程序员，也不会想过花太多时间学习如何更好地编程。

模型驱动软件开发 (MDSD) 和 领域特定语言 (DSL) 之间有什么联系？

在 MDSD 的上下文中看到“DSL”一词是很常见的。事实上，一些 MDSD 人士似乎认为 DSL 只存在于 MDSD 世界中。最近我一直在为我的书写很多关于 DSL 的内容，但到目前为止，我还没有真正触及 MDSD 的角度。相反，我一直专注于 DSL 在更传统的编程中的作用。DSL 存在于文本语言和 MDSD 世界中，并且在两者中扮演着几乎相同的作用。

Sergey Dmitriev 是 JetBrains 的领导者之一，该公司为我们提供了 IntelliJ Idea 和 ReSharper 等优秀工具。他最近发表了一篇文章，介绍了他所做的一些探索性开发工作，称为元编程系统。他认为该系统是他称之为面向语言编程的更广泛运动的一个例子。

模型驱动软件开发 (MDSD) 是一种软件开发风格，它认为自己是传统编程风格的替代方案。该方法的核心是构建软件系统的模型。这些模型通常通过图表设计符号来体现 - UML 就是其中一种选择。其理念是使用这些图表向建模工具指定系统，然后使用传统的编程语言生成代码。

Oslo 是微软的一个项目，人们对此早有耳闻，但直到本周的 PDC 大会才透露更多细节。我们所知道的是，它与模型驱动软件开发和领域特定语言有关。

这些天，我与很多人谈论领域特定语言，对于外部 DSL，一个常见的反应是很难编写解析器。事实上，使用 XML 作为外部 DSL 的载体语法的一个理由是“解析器是现成的”。这与我的经验不符 - 我认为解析器的编写比大多数人想象的要容易得多，而且并不比解析 XML 难。

Ruby 最受欢迎的功能之一是它对元编程的支持，即那些看起来像是在改变语言本身的功能 - 引入了新关键字之类的东西。

我应该使用规则引擎吗？

在谈论领域特定语言（或任何计算机语言）时，一个常见的词是语法噪音。人们可能会说 Ruby 比 Java 的噪音小，或者外部 DSL 比内部 DSL 的噪音小。语法噪音指的是那些不是我们真正需要表达的意思的一部分，而是为了满足语言定义而存在的额外字符。噪音字符是不好的，因为它们会掩盖程序的含义，迫使我们去费力地理解它在做什么。

XML 已经出现一段时间了，而且它的使用非常广泛 - 事实上比它应该的要广泛得多。像大多数工具一样，XML 适用于某些方面，而不适用于其他方面。